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----------------------------------------------------------------------

Date: 30 Sep 93 05:31:01 GMT
From: ogicse!uwm.edu!spool.mu.edu!wupost!csus.edu!netcom.com!fmitch@network.ucsd.edu
Subject: <none>
To: ham-digital@ucsd.edu

Nels Harvey (NHAR000@MUSIC.LIB.MATC.EDU) wrote:

: In the Southeastern Wisconsin area, we are trying to upgrade the
: backbone from 4800 baud to 9600 baud.  My problem is, a Kantronics data
: engine, an MFJ 1274, an MFJ 9600 baud modem, a deviation of 3 KHz. all
: at about 200 ft. doesn't work!  4800 baud works fine!

: We are using Icom 3200's as part of the 9600 baud network.  They talk
: to each other!

: I'm open to any suggestions to get this Kilobuck project resolved.  We
: don't have a path problem, this isn't working on the bench!  Is there
: something I've overlooked?

: Has anyone had problems with the Data Engine?

Hi Nels.  I am using the Data Engine with a Alinco DR-1200 on the
DX Cluster backbone here in Mobile and it works great.  At last
count, we had 19 Data Engines (most running BPQ code) on the
Gulf Net Backbone.  They work great.  I suggest you get a good
service monitor and look at your rf.  The best service monitor
we have found to use is an IFR1200S.  You can tell instantly
by the "eye" pattern on the sm what the source of your problem
is.  You can see if you have too much phase jitter (multiple
squiggly lines), AMing (multiple top and bottom lines) or just
plain distortion.  The service monitor is the *_ONLY_* way to
get your 9600 going!  I speak from experience!  The expert
on Data Engines and 9600 baud is Jim Moore, WU3V in Lafayette,
LA., 318-893-9455 home, 318-231-6141 work.  Good luck!

Mitch, WA4OSR

-- 
fmitch@netcom.com
Felton Mitchell, WA4OSR in Mobile, Alabama USA
co-sysop for W4IAX bbs running fbb ... sysop for WA4OSR DXCluster in Mobile..

------------------------------

Date: Wed, 29 Sep 1993 17:15:22 GMT
From: news.service.uci.edu!ttinews!calvin.tti.com!cole@network.ucsd.edu
Subject: Any experience from delta modulation??
To: ham-digital@ucsd.edu

In article <1993Sep28.132547.13088@ke4zv.atl.ga.us> gary@ke4zv.atl.ga.us (Gary Coffman) writes:

>You may want FEC, but resends generally are not satisfactory. You have
>to reproduce a continous speech stream, and resends will be unacceptable
>at speeds we can reasonably muster. What you do instead is simply output
>the bad bits as a brief noise burst, or output a 50% level for bits you
>know are bad. IE if you're encoding with 8 bits, uncorrectable bad bytes
>are output as 128. Speech is redundant, and there is context to help even
>further, so brief strings of uncorrectable bit errors only add a bit of
>static to the signal. 

There are many ways to deal with a known bad speech sample, but
outputting a "50% level" isn't one of them.  The simplest is to
repeat the previous sample.  A better, but not quite as simple,
method is to interpolate between the preceding and following samples.
An evnn better way is to run a short predictor at the decoder.

The original poster was talking about delta modulation, so we're
not talking about bad output speech samples anyway, but rather
about bad quantized deltas.  The effects of a single error can be
felt for a long time.

In a packet system the lower-level protocols probably aren't going
to pass up bad packets anyway.

The first packet voice experiments I know of were done in 1974
over what was then called the Arpanet.  Interestingly enough, delta 
modulation was used for those experiments, namely 8 kilobit/sec CVSD.

Randy Cole
KN6W
cole@soldev.tti.com

------------------------------

Date: Wed, 29 Sep 93 01:17:19 -0400
From: psinntp!wlnntp.psi.com!usenet@uunet.uu.net
Subject: FTP source for JNOS 1.08
To: ham-digital@ucsd.edu

>DATE:   Tue, 21 Sep 1993 14:34:02 -0600
>FROM:   Burt Kaufman <Burt.Kaufman@f40.n382.z1.fidonet.org>
>
>Can anybody point me to a site that has JNOS version 1.08c available for 
>anonymous FTP?

Go right to the "source" -- the host is wg7j.ece.orst.edu -- and I 
believe the directory names are the version numbers.  You'll have to 
check that...

>If possible, simple instructions on how to initiate the transfer would 
>be helpful as well.

Try the "man ftp" command if you are on a Unix system to read the FTP 
manual pages.

ftp wg7j.ece.orst.edu  
will open an FTP connection to the specified host

you can issue a "?" to see the list of commands or "?,<command>" with 
no quotes or brackets to see a one-line description of <command>.

Use "cd" to change directories on the remote, "ls" or "dir" 
to get directory listings.

This one is a MUST for retrieving anything but simple text files -- 
"binary" which sets binary mode (ascii is the default) and must be used 
for any compressed files, including .zip files.

To actually retrieve the file, use the "get" command:
get xyz.zip
assuming you have already set the curent directory.  Or, use the full 
path.

Then use exit or quit (I forget which) to close the connection and 
leave FTP.  Happy hunting!

-Seth

------------------------------

Date: Thu, 30 Sep 1993 03:07:38 GMT
From: munnari.oz.au!bunyip.cc.uq.oz.au!un!gc034@uunet.uu.net
Subject: MULTICOMM V3.0
To: ham-digital@ucsd.edu



------------------------------

Date: Thu, 30 Sep 1993 00:13:42 GMT
From: munnari.oz.au!bunyip.cc.uq.oz.au!un!gc034@network.ucsd.edu
Subject: MULTICOMM V3.0
To: ham-digital@ucsd.edu



------------------------------

Date: Wed, 29 Sep 1993 04:35:41 GMT
From: agate!spool.mu.edu!umn.edu!csus.edu!netcom.com!kors@ames.arpa
Subject: News via FM Subcarriers/receiving data broadcasts
To: ham-digital@ucsd.edu

: Anyone out there have any experience getting news & stock info via FM
: subcarrier?  

: Most of the wire services are now sending stories out this way, as are lots
: of smaller, specialized information services.   

: Some of this info appears to be encrypted; anyone know anything about
: that?  What are the best receivers & software packages?  

I've tried a lot of systems, most of which are usless for serious stock
trading. The closest that is a real tool is from Data Broadcasting Cor[poration
of San Mateo, CA. I suggest you contact them for detailed information.  I have
my SCA receiver for sale are a very good price if you think you'd like to
work with them..  The coding they use is impossible to hack (never say never),
but good luck.  There are simplerr way to beat their system, but of course are all illegal.

kors@netcom.com

------------------------------

Date: 29 Sep 93 17:41:04 GMT
From: swrinde!cs.utexas.edu!uwm.edu!biosci!joes!shibumi@network.ucsd.edu
Subject: News via FM Subcarriers/receiving data broadcasts
To: ham-digital@ucsd.edu

jubois@netcom.com (Jeff Ubois) writes:
>Some of this info appears to be encrypted; anyone know anything about
>that?  What are the best receivers & software packages?  

The ones sold by the service providers -- this information is not intended
for general public consumption (except by subscription) and is protected by 
ECPA.


| Kenton A. Hoover                                                            |
| P.O. Box 882643                                             +1 415 957 3614 |
| San Francisco, Kalifornia 94188-2643                shibumi@joes.garage.com |
|==============442.075+100=146.850+=444.625+131.8=440.900+114.8===============|
|  "Answer the door!  It is Phil, who brings with him the constant promise of |
|   pleasure and fulfillment in its most primitive form."                     |

------------------------------

Date: Wed, 29 Sep 1993 13:26:14 GMT
From: mulvey!rich@uunet.uu.net
Subject: Public access Packet question
To: ham-digital@ucsd.edu

mont@ibmmail.COM wrote:
: >    I have a Unix box connected to my TNC-2M rig.  I would like to set
: > up a public-access land-line BBS for Amateurs that will allow them to dial up
: > my machine, and would then put them into a shell.  This shell will
: > automatically set their call-signs, etc, and not allow them to
: > change it.  However, they will still be able to connect to our local
: > backbone system, and from there, connect to wherever they want.   I'll
: > keep a log of activity on the system, so if something goes wrong, I'll
: > know who to blame.  :-)  I'd like to give some local people who have
: > computers but no TNCs a taste of what packet can give them.
: >
: >   Since I will only allow verified Amateurs on the system, I look at
: > that as giving them permission to be control-ops for my equipment.
: >
: >    Does this sound feasible?

: This is almost exactly what we are doing where I work.   We have a
: company sponsure ham club with a tnc2, 2 com ports, and an AT.  One
: com port is connected to a data switch and is accessible from any
: phone throughout the site that has the data (rs232) option enable.

: I wrote some software for the club that listens for a connect request,
: prompts users for login info (userid & password), and if valid, then
: pipes all i/o from com1 to a tnc2 on com2.  This allows all valid
: members of the club access to the packet station right from their
: desks.  The software also supports looking up callsigns, and changing
: the packet radio's frequency (another board connected to the parallel
: port controls the radio's freq).

: I think the FCC wording for this kind of setup is "remotely controlled"
: where the control operator is controlling the station from a remote
: location.  The remotely controlled station could be controlled via
: radio link, and/or telephone lines.

: As far as forcing the packet callsign to be a certain callsign based
: on their login is not really needed.  The amatuer acting as the control
: operator is still responsible for iding the station.  However, it is
: still useful, because then the control operator doesn't have to remember
: to set it themself (it's easy to forget).

: Since you would probably share in the blame if someone illegally used
: your station you will need to be careful how you give access to users.
: You might want to have them preregister by sending you a copy of their
: license, or reguire that their call be found in the latest callbook,
: or something like that.

   Well, my plan is to allow access only to those people who have sent
me license copies and who I can reach by phone ( or repeater ;-)  While
I feel enough altruism to allow people to use my equipment, it isn't
strong enough that I'm willing to risk getting a NAL from Unc Sam, so
it's not going to be open to every Amateur in the area.

   My rational for providing them with a shell that automatically sets up
their callsign and connects them to the backbone is to eliminate the
problem you noted about forgetting to set MYCALL, and also to simplify
matters for the neophytes that I'm targeting.  

- Rich
-- 
Rich Mulvey                 Amateur Radio: N2VDS              Rochester, NY
rich@mulvey.com         "Ignorance should be painful."

------------------------------

Date: 29 Sep 93 14:28:31 GMT
From: news-mail-gateway@ucsd.edu
Subject: simtel20 going away for good
To: ham-digital@ucsd.edu

Greetings All,
  I have known for some time that the Simtel20 was going to be trashed on
the 30 of September. I have seen no word of it on this thread. I signed on
this morning and got this message:


 WSMR-SIMTEL20.ARMY.MIL, PANDA TOPS-20 Monitor 7.1(21733)-4
 The system will go down 30-Sep-93 16:00:00 until 1-Jan-2000 00:00:00
 for Final shutdown of SIMTEL20

 --------------------------------------------------------------------------
 | Unauthorized access to this computer system is prohibited and is       |
 | subject to criminal and civil penalties (18 USC 1030 and 18 USC 2701). |
 --------------------------------------------------------------------------

 Please send all SIMTEL20 problem reports via email to ACTION.

    ***  Due to funding constraints, realignment of mission  ***
    ***  functions, and Department of Army downsizing;       ***

    ***        SIMTEL20 will cease operations !!!            ***
    ***        30 SEPTEMBER 1993 - 1600 HOURS MDT            ***

    ***  There are two days more of SIMTEL20 operations!     ***
    ***                                                      ***

  If there is anything you want to download from the massive MS-DOS
archives, the next day or so is all you have.
  I still don't know if this newsgroup will be supported by the other
system at White Sands Missile Range.
  I've enjoyed the high level of technicial discussions and hope that the
other system will get this newsgroup in the future.
  My old address: lspringsteen@wsmr-simtel20.army.mil
  My new address: lsprings@wsmr-enh15.army.mil
  Packet: WB8LBZ @ K5WPH.NM.USA.NA

73 for now, Larry
-------

------------------------------

Date: Wed, 29 Sep 1993 18:46:26 GMT
From: news.service.uci.edu!paris.ics.uci.edu!csulb.edu!library.ucla.edu!agate!doc.ic.ac.uk!uknet!bnr.co.uk!bnrgate!nmerh207!corpgate!nrtpa038!brtph560!b4pph13e!cnc23a@network.ucsd.edu
Subject: Soundblaster (tm) for multi-mode digital communications ??
To: ham-digital@ucsd.edu

I recently saw an advertisement in QST of a software program that will 
use the Soundblaster(tm) for SSTV decoding.  I know of a public domain program
that uses the Soundblaster(tm) for DTMF decode.  The VOICEBLASTER (tm) product 
will do voice recognition.

This leads to a simple question : "Can the Soundblaster (tm) be programmed to 
do all the 1200, 2400, 9600, afsk, psk, etc. TNC work, (Color) SSTV, WEFAX,
RTTY, CW, AMTOR, FAX, PACTOR, CCTSS, DTMF, etc. etc. work that a multi-mode digital controller does ?" I realize there would need to be some sort of IO 
board/port to to tramsmitter keying, but is it possible ?



-- 
======================================================================

Ken M. Edwards, PE  Bell Northern Research, Research Triangle Park, NC
(919) 481-8476 email: cnc23a@bnr.ca    Ham: N4ZBB

All opinions are my own and do not necessarily reflect the views of
my employer or co-workers, family, friends, congress, or president.

Let this be the day...
  when you stop just thinking about your dreams,
  and you start doing something to make them happen!
Let this be the day...
  you give your best,
  believe that you can make a difference in the world,
  because it's true!
Let this be the day...
  when you can honestly say
  you've lived life to the fullest.
                                     Linda Lee Elrod

------------------------------

Date: Wed, 29 Sep 1993 15:48:13 GMT
From: news.cerf.net!kaiwan.com!topolski@network.ucsd.edu
Subject: Telnet-2m Gateways?
To: ham-digital@ucsd.edu

Does anyone have a current list of the available telnet->packet gateways
available?
-- 
Robert M. Topolski <topolski@kaiwan.com>

------------------------------

Date: 29 Sep 93 16:11:51 GMT
From: news-mail-gateway@ucsd.edu
Subject: test
To: ham-digital@ucsd.edu

'lo all!
Sorry for test... but I want to know if I'm posting 100% or not
before send anything... :)))

ROD.

------------------------------

Date: 29 Sep 1993 03:37:45 GMT
From: dog.ee.lbl.gov!agate!howland.reston.ans.net!sol.ctr.columbia.edu!news.unomaha.edu!crcnis1.unl.edu!unlinfo2!mcduffie@network.ucsd.edu
To: ham-digital@ucsd.edu

References <1993Sep27.141808.13231@mnemosyne.cs.du.edu>, <1993Sep27.175914.10643@news.mentorg.com>, <1993Sep28.190214.9045@mnemosyne.cs.du.edu>
Subject : Re: Responsibility for BBS messages

lkollar@nyx.cs.du.edu (Larry Kollar) writes:


~~~~~ deleted ~~~~~

>In another message, Gary McDuffie compares forging a call on packet to
>using a bogus call on a repeater.  However, repeaters are not assumed
>to be running unattended (like most packet BBSes/forwarding nodes).
>[Or are they?  Oh well, I'm sure I'll hear about it if I'm wrong. :-)]

You must live in the big city. Can you say AUTOMATIC CONTROL? I have 
no idea what the numbers are, but I would bet that over 90% of the 
repeaters in the country are run under automatic control. Under 
automatic control, a repeater is assumed to be used properly until 
evidence to the contrary is found. At that time, steps are taken to 
keep the event from happening again. There are relatively few 
repeaters that have control ops sitting on the edge of their seats, 
waiting for someone to utter the wrong words. That's the way the BBS 
network should be. Let it run. When an abuser is found, get rid of 
him. In the meantime, things flow normally and expeditiously.

>Assuming I'm right about repeaters -- the FCC figures we put up with control
>operators on repeaters; why shouldn't we put up with the equivalent on packet?

Why should we be bothered?

~~~~~ deleted ~~~~~

>--
>Larry Kollar, KC4WZK

How about this aside:

This is off the subject slightly, but it parallels the subject in the 
first paragraph. In some areas, it is considered okay to put someone 
else's call in your tnc to accomplish a specific task. This may seem 
absolutely taboo to some, but stop and think about it for a minute. If
you satisfy the requirement of identification with a UI beacon frame 
but have a different callsign in the MYCALL parm, you can check into 
the local board with whatever callsign you choose. If you originate a 
message while you are on that board, it will show it as coming from 
the callsign in your tnc, not the one you are beaconing as an ID. You 
think this can't be done? Have you ever heard of an alias? What if my 
callsign is AG0N and my alias is WB0KKM? Do you know of a rule that 
says your alias can't be something that resembles a callsign? Shall we
get deeper into discussions of callsign legality with the nodes in the
west? How about REN0 or SF0? There are many more.

Things that make you want to say hmmm.....

Gary - AG0N

------------------------------

Date: 29 Sep 93 06:50:57 GMT
From: munnari.oz.au!sol.ccs.deakin.edu.au!news.cs.uow.edu.au!mippet.ci.com.au!eram!dave@network.ucsd.edu
To: ham-digital@ucsd.edu

References <748474616snx@llondel.demon.co.uk>, <281nbg$h7j@crcnis1.unl.edu>, <CE15o6.142r@austin.ibm.com>m
Subject : Re: Responsibility for BBS messages

In article <CE15o6.142r@austin.ibm.com>,
    miltonm@austin.ibm.com (Milton D. Miller II) writes:

| Evidently, the FCC thinks it
| is too easy to forge a message in someone elses name/call.

It's as trivial as "MYCALL xxxxxx" on your TNC; a spate of which is
happening in Sydney right at this moment (and no, nothing to do with
the Olympics; it's targeted against certain individuals such as myself).

Anyone tried packet DF-ing?

-- 
Dave Horsfall (VK2KFU)    VK2KFU @ VK2RWI.NSW.AUS.OC     PGP 2.3
dave@esi.COM.AU           ...munnari!esi.COM.AU!dave    available

------------------------------

End of Ham-Digital Digest V93 #59
******************************
